Community Health

Community health workers deliver a large share of primary care in many countries, and they work under conditions that break most assumptions built into health software: no connectivity, shared or low-end devices, limited literacy in the system's language, and no technical support within a day's travel.

The architecture that results is genuinely different — not a simplified facility system, but one organised around households, tasks and intermittent synchronisation.

What makes it different

Facility system assumes	Community reality
Reliable connectivity	Days offline is normal
The patient comes to the record	The worker goes to the household
Individual-centric	Household-centric, then individual
The user is a clinician	The user may be a volunteer with brief training
Managed devices	Personal phones, shared phones, replaced phones
Continuous power	Charging is a planned activity
A support desk	The supervisor, monthly

Each row is an architectural constraint, not a UX preference.

The household as the organising unit

CHW work is organised by geography and household, not by appointment.

   Catchment area (community unit)
        └── Household
              ├── Members (individuals, with relationships)
              ├── Location (GPS, landmark description)
              ├── Characteristics (water source, sanitation, bed nets)
              └── Visit history

Individuals are enrolled into programmes — antenatal, child health, TB, chronic disease — and their tasks roll up to the household so a single visit can serve everyone in it. A CHW who has walked an hour will address every member, and a system that requires separate visits per programme will be worked around.

Household composition changes: births, deaths, marriages, migration, household splits. The model must support these as first-class events rather than as edits, or longitudinal denominators become unreliable.

Task-driven, not form-driven

The most important design distinction in this domain.

A form-driven system shows the CHW a menu of forms and expects them to know which to complete. A task-driven system tells them what is due:

   Worklist
   ────────
   ● Sunita Rai — ANC contact 3 due (2 days overdue)     ← guideline schedule
   ● Household 47 — newborn postnatal visit, day 3        ← time-critical
   ● Ram Bahadur — TB treatment follow-up                 ← programme protocol
   ● Household 12 — referral follow-up: did she attend?   ← referral loop
   ○ Household 23 — routine visit due this month          ← routine

Tasks are generated from guideline logic — the scheduling rules in a Digital Adaptation Kit — and evaluated locally, because the device may not have reached the server since the last change.

Task generation, prioritisation and expiry are the core logic of a CHW application. Getting them right is what distinguishes a system CHWs use from one they carry.

Decision support on the device

Danger sign screening, sick child assessment, treatment eligibility. These must work offline, which means:

The rules are packaged with the application, versioned explicitly
Rule updates ship as a data or configuration update, not a full app release where possible
The version of the rules used is recorded with each assessment, so a decision can be explained months later
Rule complexity is bounded by what the device can evaluate and the worker can understand

This is a real divergence from the CDS Hooks model used in facilities. Same guideline content, different execution location. See SMART Guidelines and offline-first.

Referral, and closing the loop

The CHW's referral is often the only route into the formal system, and it is where community programmes most commonly fail architecturally.

   CHW identifies danger sign
        │
        ├──▶ Referral created locally with a stable identifier
        ├──▶ Client given a slip / code (works when systems do not)
        │
        └──▶ Synced when connectivity permits
                 │
                 ▼
        Facility notified · client arrives · arrival recorded
                 │
                 ▼
        Outcome recorded ──▶ synced back to the CHW's device
                 │
                 ▼
        CHW sees the outcome; non-arrivals become follow-up tasks

The feedback path is the part that gets cut for schedule reasons and should not be. Without it the programme cannot measure whether referral works, and the CHW loses the signal that their judgement mattered.

The paper slip is not a failure of the architecture. It is a designed fallback that works when the facility system is down, the network is out, or the client arrives before the sync — and it should carry the referral identifier so the digital record can be reconciled.

Supervision

CHW programmes are held together by supervision, and the supervisor's view is a first-class part of the system:

Which workers are active, and when they last synced
Coverage: households visited against households due
Task completion and overdue rates
Referral completion rates
Data quality signals — implausible values, forms completed suspiciously fast, visits recorded far from the household's recorded location
Stock held by the worker, where they carry commodities

Design this to support supervision, not surveillance. GPS traces of workers' movements are technically easy, corrosive to trust, and frequently disproportionate. Verify visits by outcome and spot check, not by tracking.

Channels

Not every programme can deploy smartphones.

Channel	Use	Constraints
Smartphone app	Full workflow, offline, decision support	Device cost, replacement, charging, training
SMS	Reminders, simple reporting, alerts	160 characters, no structure, costs money, unreliable delivery, no confidentiality
USSD	Menu-driven interaction on any phone	Session timeouts, no offline capability, network dependent
IVR / voice	Low-literacy contexts, client messaging	Expensive, language coverage
Paper + data entry	Where devices are not viable	Delay, transcription error, but genuinely appropriate in some settings

Confidentiality on SMS deserves explicit thought. A message saying "your HIV test result is ready" arriving on a shared phone is a disclosure with real consequences. Content policy for client messaging is a governance decision, not a copywriting one.

Identity in the community

Many clients have no national identifier
Names are recorded inconsistently, and transliteration varies by worker
Households are identified by landmarks
The CHW usually knows exactly who someone is, and the system does not

Practical approach: local identifiers issued by the CHW application, resolved against the client registry on sync, with unresolved records routed to a review queue rather than either being discarded or auto-merged. The CHW's own knowledge is a matching input worth capturing — a "this is the same person as" affirmation from the worker who knows both records is stronger evidence than a string similarity score.

Platforms

Platform	Notes	Licence
Community Health Toolkit (CHT)	Purpose-built for CHW programmes: offline-first, task and schedule engine, SMS support	AGPL
CommCare	Widely deployed case management and data collection	Open core
DHIS2 Android Capture	Tracker programmes offline; strong where DHIS2 is already the HMIS	BSD
ODK / ODK-X	Data collection, with ODK-X adding case management	Apache 2.0
OpenSRP	Health worker platform used in several countries; verify current activity	Apache 2.0

All Tier 2. See platforms and offline-first.

Checklist

References

Community Health Toolkit — https://communityhealthtoolkit.org/
WHO guideline on health policy and system support to optimize community health worker programmes — https://www.who.int/publications/i/item/9789241550369
CommCare — https://www.dimagi.com/commcare/
ODK — https://getodk.org/
DHIS2 Android — https://dhis2.org/android/

What makes it different​

The household as the organising unit​

Task-driven, not form-driven​

Decision support on the device​

Referral, and closing the loop​

Supervision​

Channels​

Identity in the community​

Platforms​

Checklist​

References​